home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part2 / 10087 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.0 KB
  1. Path: mail2news.demon.co.uk!genesis.demon.co.uk
  2. From: Lawrence Kirby <fred@genesis.demon.co.uk>
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Empty String function
  5. Date: Fri, 15 Mar 96 14:50:46 GMT
  6. Organization: none
  7. Message-ID: <826901446snz@genesis.demon.co.uk>
  8. References: <1996Mar14.205741.19178@vtf.idx.com>
  9. Reply-To: fred@genesis.demon.co.uk
  10. X-NNTP-Posting-Host: genesis.demon.co.uk
  11. X-Newsreader: Demon Internet Simple News v1.27
  12. X-Mail2News-Path: genesis.demon.co.uk
  13.  
  14. In article <1996Mar14.205741.19178@vtf.idx.com>
  15.            sjjm@hawkeye.idx.com "Steve Mount" writes:
  16.  
  17. >int zemp(char *ptxt, int len)
  18. >{
  19. >static int i;
  20.  
  21. Why make i static? It would be better off as an auto variable.
  22.  
  23. >if (len == 0) len = strlen(ptxt);  // Allow null-term strings
  24.  
  25. If you are writing C code // is illegal syntax - C only supports /* */
  26. comments. A conforming compiler is required to diagnose //
  27.  
  28. >i = strspn(ptxt," \n\t");
  29. >if (i >= len) return(-1);          // -1 == EMPTY
  30. >return(i);
  31. >}
  32. >
  33. >
  34. >The problem is when the buffer is not null-terminated, which
  35. >happens a lot.  The strspn function COULD read past the end
  36. >of the buffer.... potentially WAY past it.  Possibly even into
  37. >memory not owned by the program.
  38.  
  39. Right, you *must* pass strspn() a pointer to null character terminated string 
  40. or else the call results in undefined behaviour i.e. anything can happen.
  41. There's nothing to stop strspn() calling, say, strlen() internally.
  42.  
  43. >This is where I get concerned.
  44.  
  45. With good reason!
  46.  
  47. >Anyone know if this could cause trouble, generally, and if
  48. >it could cause trouble specifically in DOS/Win/Unix (it is
  49. >used in a Unix app now).
  50.  
  51. It will almost certainly cause trouble sooner or later in just about any
  52. environment. It could easily trap in a protected enviroment if it walks
  53. outside the permitted address space. It could also become very slow.
  54.  
  55. You need to ensure that you are passing a valid string to strspn(). Perhaps
  56. you can ensure that the buffer has space to add a terminating null character
  57. or else you would have to replace the last character with a null character
  58. before the search and restore it afterwards. If the rest of the buffer
  59. was blank you would have to check that character explicitly. Something
  60. like:
  61.  
  62. int zemp(char *ptxt, int len)
  63.  
  64. {
  65.     int     i;
  66.     char    ch;
  67.  
  68.     if (len == 0) {
  69.         len = strlen(ptxt);
  70.         i = strspn(ptxt, " \n\t");
  71.  
  72.         if (i == len)
  73.             return -1;
  74.     } else {
  75.         len--;
  76.         ch = ptxt[len];
  77.         ptxt[len] = '\0';
  78.         i = strspn(ptxt, " \n\t");
  79.         ptxt[len] = ch;
  80.  
  81.         if (i == len && (ch == ' ' || ch == '\n' || ch == '\t'))
  82.             return -1;
  83.     }
  84.  
  85.     return i;
  86. }
  87.  
  88. You whould have to be careful not to pass a pointer to non-modifiable data
  89. (e.g. a string literal) if len is non-zero. The strspn() approach here
  90. is a bit messy - what other methods have you tried?
  91.  
  92. -- 
  93. -----------------------------------------
  94. Lawrence Kirby | fred@genesis.demon.co.uk
  95. Wilts, England | 70734.126@compuserve.com
  96. -----------------------------------------
  97.